第 4 層：驗證層。

第 3 層是「擋住」。但有很多東西擋不住。你沒辦法用 grep 判斷「這個業務邏輯對不對」「這個畫面符不符合設計稿」。這一層要處理的是：擋不住的東西，怎麼讓機器至少能發現。

而那個失敗的案子，把這一層交給了人。

那個案子的驗證長什麼樣

九輪人工測試
187 個問題單
12 輪修復迴圈，每輪五件

這就是它的第 4 層——人。

而且它宣告過一條最高原則：「新系統的行為必須與舊系統等價」。

那條原則寫在規範文件的顯眼處，反覆強調。

但整個 repo 裡，沒有任何一條自動化的等價測試。

一條都沒有。所謂「行為等價」的驗證方式，就是測試員打開舊系統、打開新系統、一個畫面一個畫面比對。

這是我在那個案子看到最大的結構性漏洞。

人當偵測器的問題

用人做第 4 層，有三個必然的後果。

一、會疲勞。

九輪測試不是九次一樣的品質。第一輪的測試員很仔細，第九輪的測試員已經看過幾百個畫面了。回顧裡有一段分析「疲勞的文字印記」。後期的問題單描述變短、變模糊、開始出現「同上」「類似問題」。那不是偷懶，那是人的注意力自然衰減。

二、會漏看。

Day 06 講過 UI 的沉默約束。UI 違反設計稿，什麼都不會發生。要發現只能靠人眼對照。

而人眼對照 58 份設計稿 × 幾十個頁面，漏看是必然的，不是可能。

三、成本結構完全錯誤。

找一個版型 bug 三十分鐘，修它五分鐘。

你把最貴的資源（人的注意力），用在最便宜的工作（比對）上。

我後來把這件事寫成一句話：

九輪人工測試會疲勞、會漏看，但 eval 跑九千次不會。

前提是測試案例本身設計對——而設計測試案例，正好是人該做的事。

這一層有哪些手段

一、行為等價測試（behavior parity test）

對舊系統和新系統餵同一組輸入，比對輸出。

這在遷移案是最該做而最少人做的一件事。它直接對應「行為必須等價」這條原則。把一句話變成一個會跑的東西。成本不低（要能同時跑兩套系統），但它守住的是整個遷移案的核心承諾。

二、契約測試（contract test）

那個案子有一個反覆出現的問題：前後端驗證規則不同步。前端說必填、後端沒擋；後端限長 10、前端限長 20。

原因很單純：兩邊各寫各的。

解法也很單純：從同一份來源生成。前端的驗證 schema 和後端的驗證規則，都由同一份定義產出。不同步在結構上就不可能發生。

三、快照測試（snapshot test）

直接針對 Day 06 那七十幾個「多餘欄位／多餘按鈕」問題。

把設計稿當基準，UI 產出跟它比對，有差異就擋。這樣「多了兩欄」這種事在 CI 就被抓到，不用等到測試員的眼睛。

四、eval harness

跑一組「典型業務操作」，每次 AI 改完程式就自動跑一輪，分數降了就擋。這是把「品質」變成一個可以持續量測的數字，而不是每次都要重新人工評估。

一個更根本的問題

上面四種手段都不難，也都有成熟工具。那個案子為什麼一種都沒做？

我認為關鍵在這裡：

109 個問題單修完了，沒有任何一個變成自動化測試。

每個 bug 的生命週期是：立單 → 修 → 關單。**結束。**那個 bug 教會團隊的東西，隨著關單一起消失了。所以同類問題在下一輪以變形再出現。Day 03 講的跨輪重現 47 個，就是這樣來的。正確的做法只有一句話：

任何修完的 bug，必須附帶一條自動化的回歸測試。
不附帶的，不准合。

而且這條規則本身就該是第 3 層的（用 CI 擋），不是第 0 層的（寫在文件裡）。每個 bug 都是一顆免費的種子。 它已經證明了「這裡會出錯」，你只要把它種下去，它就永遠幫你守著那個位置。

那個案子有 187 顆種子，一顆都沒種。

驗證層的定位

要講清楚一件事：第 4 層是 detective，不是 preventive。 它不擋，它只是發現得比人早、比人準、比人便宜。那它跟第 3 層怎麼分工？我的判準是：

「這個檔案有沒有放對目錄」。第 3 層，grep 就知道。
「這個計算結果對不對」——第 4 層，要跑才知道。
「這個業務規則該不該存在」——第 5 層，要問人。

而那個案子把第三類以外的東西，全部丟給了第 5 層。

從問題單長出 eval

最後給一個很實際的做法，成本低、效果好：

把測試問題單當成 eval 的種子。

每個問題單修完的時候，順手把它變成一條自動化測試。跑久了你會累積出一組專屬於這個專案的回歸測試集。而且每一條都對應一個真的發生過的失敗。這比任何「best practice 測試清單」都準，因為它是從你自己的坑裡長出來的。

那個案子如果從第一個問題單就這樣做，到第 187 個的時候會有 187 條回歸測試。而 1 月 27 日那 72 個裡面，有多少會被擋住？

我猜至少一半。

小結

• 第 4 層那個案子交給了人——九輪測試、187 個問題單、12 輪修復
• 人當偵測器必然會疲勞、漏看，而且成本結構錯誤（最貴的資源做最便宜的工作）
• 手段：行為等價測試、契約測試、快照測試、eval harness
• 最根本的問題是：109 個 bug 修完，沒有一個變成測試——種子全部浪費了
• 判準：能擋的擋（第 3 層）、要跑才知道的測（第 4 層）、要判斷的留給人（第 5 層）

明天是 Part 1 最後一天，講第 5 層：人。以及一件很多人搞反的事。人到底該做什麼。